@aktau Could you add a test for this?

I'm not really sure how to do that, before this project I had never even touched node.js and even though I knew js I'm not really familiar with the testing frameworks.

I'm assuming you would have to make a server that:

1. keeps a request alive
2. returns a non-recogized status code like 502

Then you would have to check that the request does not hang. I really have no idea how to this since you can't get at the request (it's rightfully not exposed) and there is no real way to see if it hangs afaik because the only way I noticed it is by seeing that my node process did not exit properly.

That said, this is a one-line change that can't (imho) really do much wrong. The request provoked an error, it needs to end anyway, nothing productive can still be done on that request (as far as websockets is confirmed). So it doesn't do any harm to close it.

+1 for fixing this issue.
It can also be caused by sending an error status in response to an upgrade request.
I'll see if I can work out a test.

#271

I fixed it slightly differently in that I expose the request and response in the error object.
This:

• Keeps existing behaviour if nothing else is done.
• Gives a chance to call request.abort() if required.
• Gives a chance to read the data from the response (or other header values). This can be very useful when you want to return extra error information!

@aktau @3rd-Eden Is this a good approach do you think?

Closing this as it has been addressed by #271.
Thank you!